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Abstract 

The condition of ^-resilience stipulates that an n-process program is only obliged to make 
progress when at least n — t processes are correct. Put another way, the live sets, the collection 
of process sets such that progress is required if all the processes in one of these sets are correct, 
are all sets with at least n — t processes. 

We show that the ability of arbitrary collection of live sets C to solve distributed tasks is 
tightly related to the minimum hitting set of C, a minimum cardinality subset of processes that 
has a non-empty intersection with every live set. Thus, finding the computing power of C is 
./VP-complete. 

For the special case of colorless tasks that allow participating processes to adopt input or 
output values of each other, we use a simple simulation to show that a task can be solved C- 
resiliently if and only if it can be solved (h — l)-resiliently, where h is the size of the minimum 
hitting set of C. 

For general tasks, we characterize £-resilient solvability of tasks with respect to a limited 
notion of weak solvability: in every execution where all processes in some set in C are correct, 
outputs must be produced for every process in some (possibly different) participating set in C. 
Given a task T, we construct another task Tc such that T is solvable weakly £-resiliently if and 
only if Tc is solvable weakly wait-free. 



1 Introduction 

One of the most intriguing questions in distributed computing is how to distinguish solvable from 
the unsolvable. Consider, for instance, the question of wait-free solvability of distributed tasks. 
Wait-freedom does not impose any restrictions on the scope of considered executions, i.e., a wait- 
free solution to a task requires every correct processes to output in every execution. However, 
most interesting distributed tasks cannot be solved in a wait-free manner (6j[T9]. Therefore, much 
research is devoted to understanding how the power of solving a task increases as the scope of 
considered executions decreases. For example, t-resilience considers only executions where at least 
n — t processes are correct (take infinitely many steps) , where n is the number of processes in the 
system. This provides for solving a larger set of tasks than wait-freedom, since in executions in 
which less than n — t processes are correct, no correct process is required to output. 
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What tasks are solvable f-resiliently? It is known that this question is undecidable even with 
respect to wait-free solvability, let alone t-resilient (9j Ej. But is the question about t-resilient 
solvability in any sense different than the question about wait-free solvability? If we agree that 
we "understand" wait-freedom |16j . do we understand t-resilience to a lesser degree? The answer 
should be a resounding no if, in the sense of solving tasks, the models can be reduced to each other. 
That is, if for every task T we can find a task T which is solvable wait-free if and only if T is 
solvable t-resiliently. Indeed, [2j HI [8] established that t-resilience can be reduced to wait-freedom. 
Consequently, the two models are unified with respect to task solvability. 

In this paper, we consider a generalization of t-resilience, called C-resilience. Here C stands 
for a collection of subsets of processes. A set in C is referred to as a live set. In the model 
of /^-resilience, a correct process is only obliged to produce outputs if all the processes in some 
live set are correct. Therefore, the notion of /^-resilience represents a restricted class of adversaries 
introduced by Delporte et al. \5\, described as collections of exact correct sets. C- resilience describes 
adversaries that are closed under the superset operation: if a correct set is in an adversary, then 
every superset of it is also in the adversary. 

We show that the key to understanding /^-resilience is the notion of a minimum hitting set of 
C (called simply hitting set in the rest of the paper). Given a set system (II, C) where II is a set of 
processes and £ is a set of subsets of II, H is a hitting set of (II, C) if it is a minimum cardinality 
subset of IT that meets every set in C. Intuitively, in every £-resilient execution, i.e., in every 
execution in which at least one set in C is correct, not all processes in a hitting set of C can fail. 
Thus, under /^-resilience, we can solve the k-set agreement task among the processes in II where 
k is the hitting set size of (II, £). In fc-set agreement, the processes start with private inputs and 
the set of outputs is a subset of inputs of size at most k. Indeed, fix a hitting set H of (II, £) of 
size k. Every process in H simply posts its input value in the shared memory, and every other 
process returns the first value it witnesses to be posted by a process in H. Moreover, using a simple 
simulation based on [21 S] , we derive that C does not allow solving (k— l)-set agreement or any other 
colorless task that cannot be solved (k — l)-resiliently. Thus, we can decompose superset-closed 
adversaries into equivalence classes, one for each hitting set size, where each class agrees on the set 
of colorless tasks it allows for solving. 

Informally, colorless tasks allow a process to adopt an input or output value of any other partic- 
ipating process. This restriction gives rise to simulation techniques in which dedicated simulators 
independently "install" inputs for other, possibly non-participating processes, and then take steps 
on their behalf so that the resulting outputs are still correct and can be adopted by any partici- 
pant [21 0]. The ability to do this is a strong simplifying assumption when solvability is analyzed. 

For the case of general tasks, where inputs cannot be installed independently, the situation is 
less trivial. We address general tasks by considering a restricted notion of weak solvability, that 
requires every execution where all the processes in some set in C are correct to produce outputs 
for every process in some (possibly different) participating set in C. Note that for colorless tasks, 
weak solvability is equivalent to regular solvability that requires every correct process to output. 

We relate between wait-free solvability and £-resilient solvability. Given a task T and a collec- 
tion of live sets C, we define a task Tc such that T is weakly solvable £-resiliently if and only if 
T£ is weakly solvable wait-free. Therefore, we characterize £-resilient weak solvability, as wait-free 
solvability has already been characterized in [16J. Not surprisingly, the notion of a hitting set is 
crucial in determining Tc- 

The simulations that relate T and Tc are interesting in their own right. We describe an agree- 
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ment protocol, called Resolver Agreement Protocol (or RAP), by which an agreement is immediately 
achieved if all processes propose the same value, and otherwise it is achieved if eventually a single 
correct process considers itself a dedicated resolver. This agreement protocol allows for a novel 
execution model of wait-free read-write protocols. The model guarantees that an arbitrary number 
of simulators starting with j distinct initial views should appear as j independent simulators and 
thus a (j — l)-resilient execution can be simulated. 

The rest of the paper is organized as follows. Section [2] briefly describes our system model. 
Section [3] presents a simple categorization of colorless tasks. Section [4] formally defines the wait- 
free counterpart Tc to every task T. Section [5] describes RAP, the technical core of our main 
result. Sections [6] and [7] present two directions of our equivalence result: from wait-freedom to 
/^-resilience and back. Section [8] overviews the related work, and Section [9] concludes the paper 
by discussing implications of our results and open questions. Most proofs are delegated to the 
technical report [ID] . 

2 Model 

We adopt the conventional shared memory model [12], and only describe necessary details. 
Processes and objects. We consider a distributed system composed of a set II of n processes 
{pi, . . . ,p n } (n > 2). Processes communicate by applying atomic operations on a collection of shared 
objects. In this paper, we assume that the shared objects are registers that export only atomic read- 
write operations. The shared memory can be accessed using atomic snapshot operations |1J. An 
execution is a pair (/, a) where I is an initial state and a is a sequence of process ids. A process 
that takes at least one step in an execution is called participating. A process that takes infinitely 
many steps in an execution is said to be correct, otherwise, the process is faulty. 
Distributed tasks. A task is defined through a set I of input n-vectors (one input value for 
each process, where the value is _L for a non-participating process), a set O of output n-vectors 
(one output value for each process, _L for non-terminated processes) and a total relation A that 
associates each input vector with a set of possible output vectors. A protocol wait-free solves a 
task T if in every execution, every correct process eventually outputs, and all outputs respect the 
specification of T. 

Live sets. The correct set of an execution e, denoted correct (e) is the set of processes that appear 
infinitely often in e. For a given collection of live sets C, we say that an execution e is C-resilient 
if for some L E C, L C corrective). We consider protocols which allow each process to produce 
output values for every other participating process in the system by posting the values in the 
shared memory. We say that a process terminates when its output value is posted (possibly by a 
different process). 

Hitting sets. Given a set system (II, C) where £ is a set of subsets of IT, a set H C II is a hitting 
set of (II, C) if it is a minimum cardinality subset of II that meets every set in C. We denote the set 
of hitting sets of (II, C) by HS(U, £), and the size of a hitting set of (II, £) by h(U, C). By (IT, £), 
IT C II we denote the set system that consists of the elements S 6 C, such that SCI]', 
The BG-simulation technique. In a colorless task (also called convergence tasks [1]) processes 
are free to use each others' input and output values, so the task can be defined in terms of input 
and output sets instead of vectors. 

BG-simulation is a technique by which k + 1 processes q%, . . ., qt+i, called simulators, can wait- 
free simulate a /c-resilient execution of any asynchronous n-process protocol [2j 0] solving a colorless 
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task. The simulation guarantees that each simulated step of every process pj is either eventually 
agreed on by all simulators, or the step is blocked forever and one less simulator participates further 
in the simulation. Thus, as long there is a live simulator, at least n — k simulated processes accept 
infinitely many simulated steps. The technique has been later extended to tasks beyond colorless [8j. 
Weak /^-resilience. An execution is £-resilient if some set in C contains only correct processes. 
We say that a protocol solves a task T weakly C-resiliently if in every £-resilient execution, every 
process in some participating set L G C eventually terminates, and all posted outputs respect 
the specification of T. In the wait-free case, when C consists of all n singletons, weak /^-resilient 
solvability stipulates that at least one participating process must be given an output value in every 
execution. 

Weak solvability is sufficient to (strongly) solve every colorless task. For general tasks, however, 
weak solvability does not automatically implies strong solvability, since it only allows processes 
to adopt the output value of any terminated process, and does not impose any conditions on the 
inputs. 

3 Colorless tasks 

First recall the formal definition of a colorless task. Let val(U) denote the set of non-_L values in a 
vector U. In a colorless task, for all input vectors I and /' and all output vectors O and O' , such 
that (1,0) G A, val(I') C val(I), val(0') C val(0), we have (/', O) G A and (I,O f ) G A. 

Theorem 1 A colorless task T is weakly C-resiliently solvable if and only if T is (h(Tl,£) — 1)- 
resiliently solvable. 

Proof. Let a colorless task T be (h — l)-resiliently solvable, where h = h{Ii, C), and let A be the 
corresponding algorithm. Let H = qx, . . . , be a hitting set of (II, C). Since H is a hitting set of C, 
in every £-resilient execution, at least one simulator must be correct. Running BG-simulation pJH] 
of A on these h simulators, where each simulator tries to use its input value of T as an input value 
of every simulated process, results in an /i-resilient simulated execution of A. By our assumption, 
every correct process must decide in this execution. 

For the other direction, suppose, by contradiction that C solves a task T that is not possible to 
solve (h — l)-resiliently. Let Ac be the corresponding protocol. 

Consider any (h — l)-resilient execution e of Ac, and observe that e involves infinitely many 
steps of a set in C. Indeed, otherwise, there is a hitting set that does not contain at least n — h + 1 
processes (namely, the processes that appear infinitely often in e), and thus the hitting set size of 
C is at most h — 1. 

Thus, every (h — l)-resilient execution is also /^-resilient, which implies an (h — l)-resilient 
solution to T — a contradiction. □ 

Theorem [T] implies that C- resilient adversaries can be categorized into n equivalence classes, class 
h corresponding to hitting sets of size h. Note that two adversaries that belong to the same class 
h agree on the set of colorless tasks they are able to solve, and the set includes /i-set agreement. 
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4 Relating ^-resilience and wait-freedom: definitions 



Consider a set system (II, C) and a task X = (X, O, A), where X is a set of input vectors, O is a 
set of output vectors, and A is a total binary relation between them. In this section, we define the 
"wait-free" task Xc = C^'j O' , A') that characterizes /^-resilient solvability of X. The task Xc is a l so 
defined for n processes. We call the processes solving Xc simulators and denote them by s\, . . . , s n . 

Let X and X' be two n- vectors, and Z\, . . . , Z n be subsets of II. We say that X' is an image of 
X with respect to Z\, . . . , Z n if Mi, such that X'[i] ^ _L, we have X'[i] = {(j, X[j])}j £ Zi- 

Now T c = (X, O', A') guarantees that for all (X, O') G A', there exist (J, O) G A such that: 

(1) 3S\, . . . ,S n C n, each containing a set in £: 

(la) X is an image of / with respect to Si, ... , S n . 
(lb) - {J_}| = m => h(U iJI{ ^ L S h L) > m. 

In other words, every process participating in Xc obtains, as an input, a set of inputs of X 
for some live set, and all these inputs are consistent with some input vector / of X. 

Also, if the number of distinct non-_L inputs to Tc is m, then the hitting set size of the set of 
processes that are given inputs of X is at least m. 

(2) 3Ui, . . . , U n , each containing a set in C: O' is an image of O with respect to U\, . . . , U ri . 

In other words, the outputs of Xc produced for input vector / should be consistent with 
O G O such that (I, O) G A. 

Intuitively, every group of simulators that share the same input value will act as a single process. 
According to the assumptions on the inputs to Xc > the existence of m distinct inputs implies a hitting 
set of size at least m. The asynchrony among the m groups will be manifested as at most m — 1 
failures. The failures of at most m — 1 processes cannot prevent all live sets from terminating, as 
otherwise the hitting set in (lb) is of size at most m — 1. 

5 Resolver Agreement Protocol 

We describe the principal building block of our constructions: the resolver agreement protocol 
(RAP). RAP is similar to consensus, though it is neither always safe nor always live. To improve 
liveness, some process may at some point become a resolver, i.e., take the responsibility of making 
sure that every correct process outputs. Moreover, if there is at most one resolver, then all outputs 
are the same. 

Formally, the protocol accepts values in some set V as inputs and exports operations propose(v), 
v £ V, and resolveQ that, once called by a process, indicates that the process becomes a resolver for 
RAP. The propose operation returns some value in V, and the following guarantees are provided: 
(i) Every returned value is a proposed value; (ii) If all processes start with the same input value 
or some process returns, then every correct process returns; (iii) If a correct process becomes a 
resolver, then every correct process returns; (iv) If at most one process becomes a resolver, then at 
most one value is returned. 

A protocol that solves RAP is presented in Figure [TJ The protocol uses the commit-adopt 
abstraction (CA) [7j exporting one operation propose(v) that returns (commit, v') or (adopt, v'), 
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Shared variables: 
D, initially _L 
Local variables: 

resolver, initially false 
propose(v) 

1 {flag, est) := CA.propose(v) 

2 if flag = commit then 

3 D := est; return(est) 

4 repeat 

s if resolver then D := est 

6 until D/l 

7 return(D) 
resolveQ 

8 resolver := true 



Figure 1: Resolver agreement protocol: code for each process 

for v, v' G V, and guarantees that (a) every returned value is a proposed value, (b) if only one 
value is proposed then this value must be committed, (c) if a process commits a value v, then 
every process that returns adopts v or commits v, and (d) every correct process returns. The 
commit-adopt abstraction can be implemented wait-free [7]. 

In the protocol, a process that is not a resolver takes a finite number of steps and then either 
returns with a value, or waits on one posted in register D by another process or by a resolver. A 

considers the agreement protocol stuck. An agreement 
protocol for which a value was posted in D is called resolved. 

Lemma 2 The algorithm in Figure^ implements RAP. 

Proof. Properties (i) and (ii) follow from the properties of CA and the algorithm: every returned 
value is a proposed value and if all inputs are v or some process returns (after writing a non-_L 
value v in D), then every process commits on v and returns v in line[3j 

If there is a correct resolver, it eventually writes some value in D (line[5|, and eventually every 
other process returns some value, and thus property (iii) holds. 

Moreover, a returned value either was committed in an instance of CA or was written to D by 
a resolver. Even if some process returned a value v committed in CA, then by the properties of 
CA, the only value that a resolver can write in D is v. Thus, if there is at most one resolver, the 
protocol can return at most one value, and property (iv) holds. □ 



6 From wait-freedom to ^-resilience 

Suppose that Tc is weakly wait-free solvable and let Ac be the corresponding wait-free protocol. 
We show that weak wait-free solvability of Tc implies weak £-resilient solvability of T by presenting 
an algorithm A that uses Ac to solve T in every £-resilient execution. 

First we describe the doorway protocol (DW), the only ^-dependent part of our transformation. 
The responsibility of DW is to collect at each process a subset of the inputs of T so that all the 
collected subsets constitute a legitimate input vector for task Tc (property (1) in Section [4]). The 
doorway protocol does not require the knowledge of T or Tc and depends only on C 



process that waits for an output (lines 4p 
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Shared variables: 

Rj, j = 1, . . . , n, initially _L 
Local variables: 

Sj,j = l,..., h(U, C), initially 

£j, j = 1, . . . , /i(n, £), initially 

9 Ri :— input value of T 

10 wait until snapshot(Ri, . . . , R n ) contains inputs for some set in C 
n while true do 

12 S := {pi G P,Ri 7^ -L} {the current participating set} 

13 if Pi £ H s then {H s is deterministically chosen in HS(S,£)} 

14 m :— the index of Pi in H s 

15 RAP^ .resolveQ 

is for each j = 1, . . . , \H S \ do 
17 if ij = then 

is Sj := S 1 

19 take one more step of RAP ? .propose(Sj) 

i . J 

20 if RAP J .propose(S j) returns v then 

21 (flag, Sj) := CA? .propose(v) 

22 if (flag = commit) then 

23 return({(s, R s )} Ps es ) {return the set of inputs of processes in Sj} 

24 i 3 := li + 1 

Figure 2: The doorway protocol: the code for each process pi 



In contrast, the second part of the transformation described in Section 6.2 does not depend on 



C and is implemented by simply invoking the wait-free task Tc with the inputs provided by DW. 
6.1 The doorway protocol 

Formally, a DW protocol ensures that in every £-resilient execution with an input vector I € I, 
every correct participant eventually obtains a set of inputs of T so that the resulting input vector 
I' € Tc complies with property (1) in Section [4] with respect to /. 

The algorithm implementing DW is presented in Figure [2j Initially, each process pi waits until 
it collects inputs for a set of participating processes that includes at least one live set. Note that 
different processes may observe different participating sets. Every participating set S is associated 
with H s G HS(S,£), some deterministically chosen hitting set of (S,C). We say that H is a 
resolver set for TI: if S is the participating set, then we initiate \H S \ parallel sequences of agreement 
protocols with resolvers. Each sequence of agreement protocols can return at most one value and 
we guarantee that, eventually, every sequence is associated with a distinct resolver in H s . In every 
such sequence j, each process pi sequentially goes through an alternation of RAPs and CAs (see 
Section [5}: RAP), CA), RAP?, CA?, .... The first RAP is invoked with the initially observed set of 
participants, and each next CA (resp., RAP) takes the output of the previous RAP (resp., CA) as 
an input. If some CAj returns (commit, v), then pi returns v as an output of the doorway protocol. 

Lemma 3 In every C-resilient execution of the algorithm in Figure^ starting with an input vector 
I, every correct process pi terminates with an output value and the resulting vector I' complies 
with property (1) in Section^ with respect to I. 

Proof. Consider any £-resilient execution of the algorithm. We say that an agreement sequence j 
is triggered if some process pi accessed RAP), the first RAP instance in the sequence, in line 19 
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First, we observe that if a sequence j is triggered, then value Sj proposed to its first RAP instance 
by any process pi (we simply say pj proposes Sj to sequence j) is such that Sj is a set of participants 



containing a live set and h(Sj,C) > j (lines 10 and 12-18). Recall that for all process subsets 



S and S' such that S C S' , we have h(S,C) < h(S',C)\. By the properties of atomic snapshot 
(line 10), for every two sets Sj and Si proposed to sequences j and I such that j < £, we have 
Sj c Sg. 

Consider any £-resilient execution of the algorithm. Let S be the set of participants in that 
execution. Every value returned by the protocol must be committed in some GA- , 1 < j ' < \H \ 
(line 21). By the properties of CA, every committed value is adopted by every process and then 
proposed to the next instance of RAP (line 19). By the properties of CA and RAP, every value 
returned by an instance of CA or RAP was previously proposed to the instance, and thus, no two 
different values can be returned in a given agreement sequence. Let m be the highest agreement 
sequence in which some value S m was returned. Thus, at most m distinct sets Si, . . . , S m are 
returned in total and all of these sets are subsets of S m . Thus, Ujjty^xSj = S m . Recall that 
h(Uj,r\j]^± Sj,C) = h(S m ,C) > m and property (lb) holds. Finally, resulting /' is an image of I 
with respect to some sequence Si, ... , S m where each Sj is a superset of a live set, and property 
(la) also holds. 

To show liveness, we first observe that in an £-resilient execution, line 10 is non-blocking. 
Further, the body of the cycle in lines 12-24 contains no blocking statements. Thus, every correct 
process returns or goes through infinite number of cycles, trying to advance all triggered agreement 
sequences 1, . . . , \H S \, where S is the participating set. 

To prove that every correct process terminates, it is sufficient to show that at least one process 
returns. Indeed, suppose that a process pi returns after having committed on a set Sj in some CA? 
(line 21). If a process returns from an instance of RAP, then every correct process returns from 

the instance (property (ii) of RAP). Also, every correct process returns from each instance of CA. 

i . 

Thus, every correct process eventually reaches GA - . By the properties of CA, every process that 
returns in CA - , adopts or commits Sj . By properties (i) and (ii) of RAP, every correct process 
returns Sj in RAPj +l . By the properties of CA, every correct process commits S ? - in CA/ +1 , and 

J 3 ' J 3 

returns. 

Suppose, by contradiction that no process ever returns. Eventually, all correct processes find 



the same set of participants S in line 12 and, thus, agree on the assigned hitting set H s of (S, C). 
In an £- resilient execution, at most \H S \ — 1 processes in H can fail. Otherwise, H s is not a 
hitting set, since it does not meet every live set subset of S. In a given agreement sequence j, every 
RAP ? is eventually associated with a distinct resolver in H b . Thus, by property (iii) of RAPs 
there exists an agreement sequence j S {1, . . . , |-£f s |}, that is eventually associated with a distinct 
correct resolver p r in H s . Since, eventually, p r is the only resolver of RAPs in sequence j and, by 

our assumption, agreement sequence j goes through an infinite number of RAP instances, there 

i . 

is an instance RAP? in which p r is the only resolver and, by property (iv) of RAPs, exactly one 

value Sj is returned to every correct process. Thus, every correct process commits on Sj in CA^ 
and returns — a contradiction. □ 



8 



6.2 Solving T through the doorway 



Given the DW protocol described above, it is straightforward to solve T by simply invoking Ac 
with the inputs provided by DW. Thus: 

Theorem 4 Task T is weakly C-resiliently solvable if Tc is weakly wait-free solvable. 

Proof. By Lemma [3j every execution of DW starting with an input vector / makes sure that each 
process is assigned a set of inputs of T for some participating live set, and property (1) of Tc is 
satisfied with respect to I and the resulting vector I'. Now we use Ac with I', and, by the property 
(2) of Tc, at least one participating set in £ obtains outputs. □ 



7 From ^-resilience to wait-freedom 

Suppose T is weakly £-resiliently solvable, and let A be the corresponding protocol. We describe 
a protocol Ac that solves Tc by wait-free simulating an /^-resilient execution of A. 

For pedagogical reasons, we first present a simple abstract simulation (AS) technique. AS 
captures the intuition that a group of simulators sharing the initial view of the set of participating 
simulated codes should appear as a single simulator. Therefore, an arbitrary number of simulators 
starting with j distinct initial views should be able to simulate a (j — l)-resilient execution. 

Then we describe our specific simulation and show that it is an instance of AS, and thus it 
indeed generates a (j — l)-resilient execution of £, where j is the number of distinct inputs of Tc- 
By the properties of Tc, we immediately obtain a desired £-resilient execution of A. 

7.1 Abstract simulation 

Suppose that we want to simulate a given n-process protocol, with the set of codes {code±, . . . , code n }. 
Every instruction of the simulated codes (read or write) is associated with a unique position in N. 
E.g., we can enumerate the instructions as follows: the first instructions of each simulated code, 
then the second instructions of each simulated code, etc[j] 

A state of the simulation is a map of the set of positions to colors {U, IP, V}, every position can 
have one of three colors: U (unvisited), IP (in progress), or V (visited). Initially, every position 
is unvisited. The simulators share a function next that maps every state to the next unvisited 
position to simulate. Accessing an unvisited position by a simulator results in changing its color to 
IP or V. 

The state transitions of a position are summarized in Figure [3j and the rules the simulation 
follows are described below: 

(AS1) Each process takes an atomic snapshot of the current state s and goes to position next(s) proposing state s. 
For each state s, the color of next(s) in state s is U. 

- If an unvisited position is concurrently accessed by two processes proposing different states, then it is assigned 
color IP. 

- If an unvisited position is accessed by every process proposing the same state, it may only change its color 
to V. 

- If the accessed position is already V (a faster process accessed it before), then the process leaves the position 
unchanged, takes a new snapshot, and proceeds to the next position. 

1 In fact, only read instructions of a read-write protocol need to be simulated since these are the only steps that 
may trigger more than one state transition of the invoking process [2] [4]. 
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Figure 3: State transitions of a position in AS. 



(AS2) At any point in the simulation, the adversary may take an in-progress (IP) position and atomically turn it 
into V or take a set of unvisited (U) positions and atomically turn them into V. 

(AS3) Initially, every position is assigned color U. The simulation starts when the adversary changes colors of some 
positions to V. 

We measure the progress of the simulation by the number of positions turning from U to V. 
Note that by changing U or IP positions to V, the adversary can potentially hamper the simulation, 
by causing some U positions to be accessed with different states and thus changing their colors to 
IP. However, the following invariant is preserved: 

Lemma 5 If the adversary is allowed at any state to change the colors of arbitrarily many IP 
positions to V , and throughout the simulation has j chances to atomically change any set of U 
positions to V , then at any time there are at most j — 1 IP positions. 

Proof. Note that in the periods when the adversary does not move, every new accessed position 
may only become visited. Indeed, even though the processes run asynchronously, they march 
through the same sequence of snapshots. Every snapshot a process takes is either a fresh view that 
points to a currently unvisited position, or was previously observed by some process and it points 
to a visited position. In both cases, no new IP position can show up. 

Now suppose that the adversary changed the color of a position from IP to V, thus decreasing 
the number of IP positions by one. This may result in one distinct inconsistent (not seen by any 
other simulator) state that points (through function next) to one distinct position. Thus, at most 
one position can be accessed with diverging states, resulting in at most one new IP position. Thus, 
in the worst case, the total number of IP positions remains the same. 

Now suppose that j sets of positions changed their colors from U to V, one set at a time. 
The change of colors of the very first group starts the simulation and thus does not introduce IP 
positions. Again, every subsequent group of changes can result in at most one inconsistent state, 
which may bring up to j — 1 new IP positions in total. □ 



7.2 Solving T c through AS 

Now we show how to solve Tc by simulating a protocol A that weakly £-resiliently solves T. First, 
we describe our simulation and show that it instantiates AS, which allows us to apply Lemma [5] 

Every simulator Sj 6 {s±, . . . , s n } posts its input in the shared memory and then continuously 
simulates participating codes in {code±, . . . , coden} of algorithm A in the breadth-first manner: the 
first command of every participating code, the second command of every participating code, etc. 
(A code is considered participating if its input value has been posted by at least one simulator.) 
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The procedure is similar to BG-simulation, except that the result of every read command in the 
code is agreed upon through a distinct RAP instance. Simulator Sj is statically assigned to be the 
only resolver of every read command in codei. 

The simulated read commands (and associated RAPs) are treated as positions of AS. Initially, 
all positions are U (unvisited) . The outcome of accessing a RAP instance of a position determines 



51), then it is given color 
61) by some process, then 



its color. If the RAP is resolved (a value was posted in D in line [3] or 
V (visited) . If the RAP is found stuck (waiting for an output in lines [4] 
it is given color IP (in progress). Note that no RAP accessed with identical proposals can get 
stuck (property (ii) in Section [5]). After accessing a position, the simulator chooses the first not-yet 
executed command of the next participating code in the round-robin manner (function next). For 
the next simulated command, the simulator proposes its current view of the simulated state, i.e., 
the snapshot of the results of all commands simulated so far (AS1). 

Further, if a RAP of codei is observed stuck by a simulator (and thus is assigned color IP), 
but later gets resolved by s», we model it as the adversary spontaneously changing the position's 
color from IP to V. Finally, by the properties of RAP, a position can get color IP only if it is 
concurrently accessed with diverging states (AS2). 

We also have n positions corresponding to the input values of the codes, initially unvisited. If 
an input for a simulated process pi is posted by a simulator, the initial position of codei turns into 
V. This is modeled as the intrusion of the adversary, and if simulators start with j distinct inputs, 
then the adversary is given j chances to atomically change sets of U positions to V . The simulation 
starts when the first set of simulators post their inputs concurrently take identical snapshots (AS3). 

Therefore, our simulation is an instance of AS, and thus we can apply Lemma [5] to prove the 
following result: 

Lemma 6 If the number of distinct values in the input vector ofTc is j, then the simulation above 
blocks at most j — 1 simulated codes. 

Proof. Every distinct value S in an input vector of Tc posted by a participating simulator results 
in the adversary changing some set of initial positions from U to V. (Note that the set can be 
empty if the inputs for set S has been previously posted by another simulator.) By Lemma [5j at 
any time there are at most j — 1 IP positions, i.e., at most j — 1 RAPs for read steps that are 
stuck. Thus, in the worst case, at most j — 1 simulated codes can block forever. □ 

The simulated execution terminates when some simulator observes outputs of T for at least one 
participating live set. Finally, using the properties of the inputs to task Tc (Section [4]), we derive 
that eventually, some participating live set of simulated processes obtain outputs. Thus, using 
Theorem |4j we obtain: 

Theorem 7 T is weakly C-resiliently solvable if and only if Tc is weakly wait-free solvable. 

Proof. Suppose that we are given an input vector I 1 of Tc with j distinct values, each value consists 
of inputs of T for a set of processes containing a live set. By property (la) of Tc (Section]!]), these 
input sets are consistent with some input vector / of T. We call the set of simulated processes that 
obtain inputs of T the participating set of T, and denote by IT. 

Since every simulated step goes through a RAP with a single resolver, by property (iv) of RAP 
(Section [5]), simulators agree on the result of every simulated read command, and thus we simulate 
a correct execution of algorithm A (solving T). 
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By Lemma [6J at most j — 1 processes can fail in the simulated execution of A. By property (lb) 
of Tc, the size of the hitting set of the participating set H (II' , C) is at least j. Thus, there is at least 
one live set in IT 7 that contains no faulty simulated process. This live set accepts infinitely many 
steps in the simulated execution of A and, by weak £-resilient solvability, must eventually output. 
This set of outputs constitutes the output of Tc- Since the output comes from an execution of A 
starting with /, the output satisfies property (2) of Tc- 

Thus, the algorithm indeed solves Tc- □ 



8 Related work 

The equivalence between f-resilient task solvability and wait-free task solvability has been initially 
established for colorless tasks in [21 0], and then extended to all tasks in [8j. In this paper, 
we consider a wider class of assumptions than simply i-resilience, which can be seen as a strict 
generalization of [8]. 

Generalizing t-resilience, Janqueira and Marzullo [IS] considered the case of dependent failures 
and proposed describing the allowed executions through cores and survivor sets which roughly 
translate to our hitting sets and live sets. Note that the set of survivor sets (or, equivalently, cores) 
exhaustively describe only superset-closed adversaries. More general adversaries introduced by 
Delporte et al. [5] are defined as a set of exact correct sets. It is shown in [5] that the power of an 
adversary A to solve colorless tasks is characterized by A's disagreement power, the highest k such 
that k-set agreement cannot be solved assuming A: a colorless task T is solvable with adversary A 
of disagreement power k if and only if it is solvable /c-resiliently. Herlihy and Rajsbaum [15] (con- 
currently and independently of this paper) derived this result for a restricted set of superset-closed 
adversaries with a given core size using elements of modern combinatorial topology. Theorem [I] in 
this paper derives this result directly, using very simple algorithmic arguments. 

Considering only colorless tasks is a strong restriction, since such tasks allow for definitions 
that only depend on sets of inputs and sets of outputs, regardless of which processes actually 
participate. (Recall that for colorless tasks, solvability and our weak solvability are equivalent.) 
The results of this paper hold for all tasks. On the other hand, as [15j . we only consider the class of 
superset-closed adversaries. This filters out some popular liveness properties, such as obstruction- 
freedom [13J.Thus, our contributions complement but do not contain the results in [5]. A protocol 
similar to our RAP was earlier proposed in |17j . 

9 Side remarks and open questions 

Doorways and iterated phases. Our characterization shows an interesting property of weak 
£-resilient solvability: To solve a task T weakly £-resiliently, we can proceed in two logically 
synchronous phases. In the first phase, processes wait to collect "enough" input values, as prescribed 
by C, without knowing anything about T. Logically, they all finish the waiting phase simultaneously. 
In the second phase, they all proceed wait-free to produce a solution. As a result, no process is 
waiting on another process that already proceeded to the wait-free phase. Such phases are usually 
referred to as iterated phases [3] . In [8] , some processes are waiting on others to produce an output 
and consequently the characterization in [8] does not have the iterated structure. 
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/^-resilience and general adversaries. The power of a general adversary of [5] is not exhaustively 
captured by its hitting set. In a companion paper |llj . we propose a simple characterization of 
the set consensus power of a general adversary A based on the hitting set sizes of its recursively 
proper subsets. Extending our equivalence result to general adversaries and getting rid of the weak 
solvability assumption are two challenging open questions. 
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